前文|本文_K8s网关选型初判：Nginx还是Envoy？

篇首语：本文由编程笔记#小编为大家整理，主要介绍了K8s 网关选型初判：Nginx 还是 Envoy？相关的知识，希望对你有一定的参考价值。

为了避免混淆&＃xff0c;我们先对一些关键定义做一些厘清&＃xff1a;

• 传统网关&＃xff1a;未作容器化改造&＃xff0c;未启用 K8s&＃xff0c;通过流量网关与业务网关两层网关来构建&＃xff0c;流量网关提供全局性的、与后端业务无关的策略配置&＃xff0c;例如 Tengine 就是典型的流量网关&＃xff1b;业务网关提供独立业务域级别的、与后端业务紧耦合策略配置&＃xff0c;随着应用架构模式从单体演进到现在的分布式微服务&＃xff0c;业务网关也有了新的叫法 - 微服务网关。
• K8s 网关&＃xff1a;即云原生网关&＃xff0c;也被称为下一代网关&＃xff0c;Ingress 成为 K8s 生态的网关标准&＃xff0c;促使流量网关和业务网关&＃xff0c;合二为一。基于 Ingress 规范的实现主要分为基于 nginx 和基于 Envoy 两大阵营&＃xff0c;基于 Nginx 的 Nginx Ingress Controller 是目前大多数 K8s 集群的选择&＃xff0c;基于 Envoy 的实现作为后起之秀&＃xff0c;大有赶超之势。
• MSE 云原生网关&＃xff1a;是基于 Envoy&＃xff0c;做了深度优化的云上服务。

本文将从性能和成本、可靠性、安全性 3 方面&＃xff0c;对两大开源实现进行比对&＃xff0c;希望对正在做 K8s 网关选型的企业有所借鉴。

MSE 云原生网关的吞吐性能几乎是 Nginx Ingress Controller 的一倍&＃xff0c;尤其是传输小文本时性能优势会更明显&＃xff0c;如下图所示&＃xff0c;网关 CPU 使用率达到 30% 时的吞吐对比&＃xff1a;

网关规格&＃xff1a;16 核 32 G * 4 节点

ECS 型号&＃xff1a;ecs.c7.8xlarge

当 CPU 负载升高时&＃xff0c;吞吐差距会更加明显&＃xff0c;下图是 CPU 使用率达到 70% 时的情况&＃xff1a;

高负载下 Nginx Ingress Controller 吞吐下降原因是出现了 pod 重启&＃xff0c;详情见下一节“可靠性”中的分析。

随着网络安全愈加受重视&＃xff0c;现在互联网上已经普遍使用 HTTPS 进行传输加密&＃xff0c;在网关侧&＃xff0c;用于实现 HTTPS 的 TLS 非对称加密算法是占用 CPU 资源的大头。针对此场景&＃xff0c;MSE 云原生网关使用了 CPU SIMD 技术实现了 TLS 加解密算法的硬件加速&＃xff1a;

从上图压测数据可以看出使用 TLS 硬件加速后&＃xff0c;相比普通 HTTPS 请求 TLS 握手时延降低一倍&＃xff0c;极限 QPS 提升 80%以上。

基于以上数据&＃xff0c;使用 MSE 云原生网关&＃xff0c;只需一半的资源&＃xff0c;就能达到 Nginx Ingress Controller 的吞吐&＃xff0c;在做过硬件加速优化的 HTTPS 场景下&＃xff0c;吞吐还能进一步提升。

前文提到高负载下&＃xff0c;Nginx Ingress Controller 会出现 pod 重启导致吞吐下降&＃xff0c;导致 pod 重启的原因主要有 2 点&＃xff1a;

• 存活健康检查&＃xff08;livenessProbe&＃xff09;在高负载时容易超时失败&＃xff0c;社区在 0.34 版本通过减少冗余检测进行了一定的优化&＃xff0c;但问题仍然存在。
• 在开启了 prometheus 采集监控指标的情况下&＃xff0c;高负载时会出现 OOM&＃xff0c;导致容器被 kill&＃xff0c;详细原因见相关 issue&＃xff1a;https://github.com/kubernetes/ingress-nginx/pull/8397

这两个问题&＃xff0c;本质上皆是由于 Nginx Ingress Controller 的部署架构不合理导致。其控制面&＃xff08;Go 实现的 Controller&＃xff09;和数据面&＃xff08;Nginx&＃xff09;进程混跑在一个容器内&＃xff0c;高负载下&＃xff0c;数据面进程和控制面进程出现了 CPU 抢占。其中控制面进程负责了健康检查和监控指标采集&＃xff0c;因为没有足够的 CPU 导致请求积压引起 OOM 以及健康检查超时。

这种情况是极危险的&＃xff0c;会在高负载下引发网关的雪崩效应&＃xff0c;对业务造成严重影响。MSE 云原生网关使用了数据面和控制面隔离的架构&＃xff0c;在架构上具备可靠性优势&＃xff1a;

从上图可以看到&＃xff0c;MSE 云原生网关并不部署在用户的 K8s 集群中&＃xff0c;而是纯托管的模式&＃xff0c;这种模式在可靠性上还有更多优势&＃xff1a;

• 不会与业务容器混跑在一个 ECS 节点上
• 网关的多个实例不会混跑在一个 ECS 节点上
• 提供网关可用性的 SLA 保障

如果使用 Nginx Ingress Controller 要实现高可靠部署&＃xff0c;一般需要独占 ECS 节点&＃xff0c;同时还需要部署多个 ECS 节点&＃xff0c;来避免单点故障&＃xff0c;这种情况下资源成本会直线上升。此外&＃xff0c;Nginx Ingress Controller 因为部署在用户集群中&＃xff0c;也无法提供网关可用性的 SLA 保障。

Nginx Ingress Controller 的不同版本都还存在着一些 CVE 漏洞隐患&＃xff0c;具体影响版本见下表&＃xff1a;

从 Nginx Ingress Controller 迁移到 MSE 云原生网关后&＃xff0c;将一次性修复所有 CVE 漏洞隐患&＃xff1b;并且&＃xff0c;MSE 云原生网关提供了平滑升级方案&＃xff0c;一旦出现新的安全漏洞&＃xff0c;可以快速对网关版本进行升级&＃xff0c;同时确保升级过程对业务影响最小化。

此外&＃xff0c;MSE 云原生网关内置了阿里云 Web 应用防火墙&＃xff08;WAF&＃xff09;&＃xff0c;相比传统 WAF 用户请求链路更短、RT 更低&＃xff0c;且相比Nginx Ingress Controller 可以做到细粒度路由级防护&＃xff0c;使用成本是目前阿里云 Web 应用防火墙架构的 2/3。

阿里云容器服务应用市场已经上架 MSE 云原生网关&＃xff0c;可用于替代默认安装的网关组件 Nginx Ingress Controller。

MSE 云原生网关在阿里集团内部作为网关中间件已经大规模使用&＃xff0c;其强劲的性能和可靠的稳定性已被多年双十一流量所验证。

在 K8s 容器服务场景下&＃xff0c;对比默认安装的 Nginx Ingress Controller&＃xff0c;主要有以下优势&＃xff1a;

• 更强劲的性能&＃xff0c;更合理的架构&＃xff0c;可以将网关资源成本降低至少 50%
• 更好的可靠性和 SLA 保障&＃xff0c;纯托管免运维&＃xff0c;背靠阿里云技术团队提供支持
• 更优的安全性保障&＃xff0c;一次性解决现存 CVE 安全漏洞隐患&＃xff0c;且内置 WAF 防护功能

同时在路由策略、灰度治理、可观测等方面提供了更丰富的功能&＃xff0c;并且支持使用多种语言开发自定义的扩展插件&＃xff0c;详细对比请参考&＃xff1a;
https://help.aliyun.com/document_detail/424833.html

部署 MSE 云原生网关并不直接影响原有网关流量&＃xff0c;通过 DNS 权重配置可以实现业务流量的平滑迁移&＃xff0c;对后端业务完全无感知&＃xff0c;核心的流量迁移过程如下图所示&＃xff1a;

完整步骤如下&＃xff1a;

• 步骤一&＃xff1a;在容器服务的应用市场中找到 mse-ingress-controller&＃xff0c;并安装到目标 ACK 集群
• 步骤二&＃xff1a;在 K8s 中配置 MseIngressConfig &＃xff08;配置指引&＃xff09;&＃xff0c;自动创建指定规格的 MSE 云原生网关
• 步骤三&＃xff1a;从 Ingress 的 address 字段中获取 MSE 云原生网关的 IP&＃xff0c;本地绑定 host&＃xff0c;将业务域名解析到该 IP&＃xff0c;完成业务测试
• 步骤四&＃xff1a;修改业务域名的 DNS 权重配置&＃xff0c;添加云原生网关 IP&＃xff0c;并逐步调高权重&＃xff0c;进行流量灰度
• 步骤五&＃xff1a;完成灰度后&＃xff0c;将业务域名原先的 IP 从 DNS 配置中移除&＃xff0c;实现全部流量切到云原生网关

作者&＃xff1a;张添翼(澄潭)

原文链接

本文为阿里云原创内容&＃xff0c;未经允许不得转载。